content: describe GhostKey's mechanics in the inheritance mission - #93
Merged
Conversation
Mission 74 named GhostKey without saying how it works, because its site renders only a loading state and no docs were reachable. The source is public at github.com/Jolah1/ghostKey, so the lesson now describes the actual design: a dead-man switch built from an xpub, with two spending paths on one address, the owner's usable at any time and the heir's gated behind a relative timelock. Checking in resets the countdown; letting it run out makes the heir's path spendable and sends them a claim link they can redeem into their own wallet with no account. The point the lesson leans on is the one a learner should carry to any such service: because the rule is enforced by the Bitcoin script rather than a server, the pre-built transaction still broadcasts once the timelock expires even if the company is gone. That is the difference between non-custodial and a custodian using the word, and it is what the quiz question tests. Verified by reading the lesson back through the running app bundle. Full suite green: 30 unit, 30 integration, e2e all files, tsc clean, no em dashes in the new copy. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #92. Mission 74 named GhostKey without saying how it works, because its site renders only a loading state and no docs were reachable. The source is public at Jolah1/ghostKey, so the lesson now describes the real design.
What the lesson now says
GhostKey is a dead-man switch. You paste an xpub, name an heir, choose a countdown. The coins sit at an address with two spending paths: yours, usable at any time, and your heir's, which Bitcoin refuses to allow until a relative timelock has elapsed. Tapping "I'm still here" resets the clock. Let it run out and the heir's path becomes spendable and they get a claim link, which they redeem into their own wallet with no account and nobody holding their funds.
The load-bearing point, and the one a learner should carry to any such service: because the rule is enforced by the Bitcoin script rather than a server, the pre-built transaction still broadcasts once the timelock expires even if the company is gone. That is the difference between non-custodial and a custodian using the word, and it is exactly what the quiz question added in #92 tests.
The four-question checklist stays, including "can I test the whole thing today with a small amount", which is the practical safety habit for any young tool in this category.
Verification
Read the lesson back through the running app bundle rather than trusting the source edit. Full suite green: 30 unit, 30 integration, all e2e files,
tsc --noEmitclean, no em dashes in the new copy.🤖 Generated with Claude Code